I'm going to code something from scratch. Tell me what to code.

[Thunder-squall]

PRAISE!  I GOT PRAISED! WO-HOIOO!

The things I'm currently working on are smooth movement, jumping across gaps, and placing other objects on the field, which have their unique properties.

Then some simple psi-energy interactions (push blocks; raise stone/sand; ice pillar; melt ice pillar),

and then some more complex ones (wind panels; vine growth).


A quick side note:

I kind of assume that for a lot of GS fans, the project's a non starter if they can't use the visuals they want to use (i.e. sprites).  For that reason, the map can actually be invisible, so people could use whatever kind of map they wanted (bird's eye, isometric, classic JRPG), and whatever image system they wanted (sprites, purely CG, and I even found someone who could skew tiles to those cube surfaces, to get a pseudo 3D thing going on). So if people wanted to use classic GBA Golden Sun sprites, then I'd make the cell heights a bit taller, and position the grid so player's are looking at it from the front. Or if you wanted to replace the turn-based combat style of GS with a tactics hybrid, then I think this map system cuold be adapted to that too, etc etc.

Basically, the map can be used *just* for calculations, if that's all people want from it.  It could even be overlayed over a hand-drawn map that you sketched on grid paper.  It's for that reason that I decided to hold off on sinking too much time into visuals until there's buy-in from what people want. I assume most projects won't need/want the map to change angles at all, since they'll want to use sprites.

Edit:
But that's all *in case* there's buy-in from the community.  In the case that there's not, then I simply won't have the time to invest into sprites and stuff, and even into rich story and maps.  So I'll have to settle for strong stand-alone project that I could do alone.  And that would be going from room to room, solving psi-energy puzzles within them.  That would be the base onto which I try and add conversations and story-elements.

EDIT#2:
rough update to show some stuff. One .love file and one .png file.

[Thunder-squall]

There were all sorts of problems with the draw-order which I think I solved, but I'd appreciate anyone who'd test the program to see if I missed anything. See the attachment.  Check out love2d.org to be able to run it.  Use the WASD keys to move the character, and the arrow keys to check out different angles (especially around the y axis, which you can change with <- ->)

The things which are not errors (they just haven't been addressed yet) are
> there's no collision with the grey statue yet.
> moving up or down elevations is in a straight line, rather than a hop.

Right now, the token basically has two states: standing and walking.  The next thing I'm going to work on is jumping. I.e up elevations, or between gaps.  But if I'm responsible with my RL stuff, then I'll hold off doing this until maybe Sunday.

I've been thinking about it, and I'm going to keep the fields ability to rotate, because I think that will come in handy with the battle system. You know, the whole pseudo-3D thing that Golden Sun did?

EDIT:  Crud.  See attached gif.  Could any of you replicate the problem where player token overlaps the statue in front of it?  I think this happens only at certain angles, and only when the player is moving.

[Teawater]

*Tests last love link. The one in your last post.*

Do you plan to change the movement from grid to pixel by pixel movement? (Like in Golden Sun.)

[Thunder-squall]

Should I? That'd actually be easier than what I'm doing now, but I thought grid-based would be more convenient for puzzles and psi-energy stuff. 

Spoiler for Hiden:

and it's also pre-requisite for doing tactics style battles, which I'm imagining as a nice twist on the traditional turn-based stuff. 

There'll always be free movement on the world map, and I'm also really interested in doing a castle-crashers style brawler using the same field, which would require a more action-style free movement.

But here, if you're interested, I've attached a small picture file and a lua(text) file that are used together in a small program.  It gives a quick example free movement.  You can "run" it in two ways:

1) place the png and lua file into a folder, and then drag that folder over the round blue LOVE icon that you might have on your desktop.

OR

2) select the png and lua file, and add them to a zip archive.  But instead of naming it something.zip, name it something.love. Then you can run the program by clicking on the archive.  If you want to look inside the archive, change it back form a .love to a .zip.

[Misery]

Sorry about being slow at commenting on this. I should say already that I tend to think about stuff for way too long, and on top of that... well, as I mentioned earlier, RL stuff.

Anyway, I can say you've gotten me interested in LÖVE and Lua at the very least. I've been skimming the official online Lua programming manual, and will take a closer look at the language when I have time. Perhaps this means I could help adding features in the future...

So... I see you've gotten into movement a bit. Is the color change during movement in preparation for a walk animation? I also noticed you added diagonal movement, but it's a bit quirky.

Any ideas about how to implement the jumping mechanic? All the ideas I'm getting for anything regarding collision seem to involve making a separate tilemap for every level of elevation. Not sure if that would be a good idea. I've only been thinking about it with a grid mindset, but it shouldn't be much different even if you change that.

You were talking about a growth/vine mechanic, but isn't a ladder climbing mechanic really what you're thinking about? Adding climbable vines will be trivial after that has been implemented. And about the floating platforms, I don't think they should be seen as a core mechanic.

Battles on GBA are interesting. They're all done with clever sprite movement, flipping, scaling, and pre-rendered particle effects. Keeping the ability to rotate the camera in the engine is a good idea regardless, as even with a static camera, you could set it to different angles for different rooms.

In regards to buy-in from the community, I don't think you should wait for it. Just choose a direction and go with it, in the end you'll have a working game engine that could possibly be tweaked to fit the needs of others. Put some extra care into making efficient development tools and editors, that will both make it easier for you to make a bigger game, and easier for others to mod it. Don't worry about graphics yet, and try to build a game with little reliance on graphics. I may be able to help you with creating some basic assets, but I'm terribly slow at getting anything done, so I wouldn't rely on me too much.

Story/dialogue: do you have any story ideas of your own? I strongly get the impression that you want to have a story for the sake of having it.

Have you thought any about inventory, equipment, and other menu systems?

Finally, I'll say this again: please play the games already! (GS and GS:tLA) While conceptually they have much in common with DD, they give off a completely different feeling. It should be a good way for you to get more familiar with the series, and they're a great experience to boot.

EDIT:  Crud.  See attached gif.  Could any of you replicate the problem where player token overlaps the statue in front of it?  I think this happens only at certain angles, and only when the player is moving.

Well, I can replicate it, but... I can't tell you what causes it.

I'll also take the time to point out a small graphical error that has persisted from the first version, since I haven't seen you mention it yet... see the attachment. It only happens at a specific camera angle. Feels like an extremely minor problem though.

[Thunder-squall]

Thanks for the feed back.  I'll post more when I have answers and solutions.  And there's no rush.  I'll be dealing with RL too.

@ story and stuff:  Basically, I just started building an engine with the sole purpose of seeing whether it could be done, and whether I could go all the way with it.  And now I think I can.  I had  no specific end in mind, but if I can implement a story, then that'll be a frame work for implementing larger stories.  So I just need to build a demo.

Questions
What should the user controls be?  4 direction buttons, 2 action buttons, 2 menu buttons?  What should they do?

Should I limit movement to grids, or just have it free-roaming?

[Teawater]

I would choose... um...
Buttons: Doesn't matter so long as you have a way of doing everything you need to do. But yeah, those controls would likely be what you'd start with.

From the GBA games:
A button = Interact (When there is nothing to interact with, this does whatever Select does.)
B button = For running
Start = Start menu
Select = Party menu (Psynergy/Djinn/Items/Status)

Movement: Free-roaming, I guess? (I'll wait to see what others have to say.)

[Thunder-squall]

A note on story: left to my own devices, and with no connection to Golden Sun, I'd have a story where someone wanders into a mage's tower, and needs to get to the top, going floor by floor.  Pretty simple and self contained.  Each floor may puzzles, battles, and whatever else I'm able to code.  Things I'd like to implement:

0. psi-energy puzzles.  I need to accomplish this, if nothing else.
1. Character customization (visual appearance, and maybe even character stats such as jump-height, mana pool, and elemental affinity)
2. Player Diary (allowed 1 entry per floor, to tell their own story.  First entry:  "My name is ____, and this is my story")
3. Djinn Inventory (Players will find djin or other spirit-allies within levels, which enable them to use magic)
4. Conversation sequences when you encounter djinn, or riddle-statues.

Other cool combat things to try and do would be

5. Simple turn based battles using summoned allies.  Summons may be based on djin, or other collected items.
6. Tactics battles, using summoned units.
7. SwordCraft story style combat.  I'd have to create and allow switching between basic weapons: (1) dual short swords, (2) long spear, (3) wind blade / shuriken, (4) hammer.  As in sword craft story, djinn could be called in for magic attacks, or may be "set" to player to allow elemental effects on melee attacks...  This would be a passion-project for me, if I tackle it.

To build a bigger world

8. Overworld map, which could be used to travel between separate towers/areas.
9. Town area, with NPCs
10. use actual tile-sprites.

----------------------------

now that I've written the stuff above, I think the simplest thing I could do is

1. Get psi-energy puzzles working.
2. Get an overworld map working.
3. User the overworld map to be able to travel between 4 elemental temples, and a central shrine.
4. Get a djinn inventory system in place that will allow the player to use different types of psi energy.
5. Get a level editor in place so that I can work on the 5 puzzle settings.

And I think that's as humble as I can go, in order to create a proof-of concept for a GS game.

-------

And that I've intimidated myself even more , I'm going so simplify my immediate ambition to

1. Create a single psi-energy puzzle room which players can get through.  I think this will be challenging enough... I think the only reason I'm considering the other stuff is to distract me from this one, daunting task.

[Misery]

Movement: whichever type that suits your needs best. As you've already demonstrated, free movement is easier, while you haven't really gotten grid-locked movement to be fluid yet. On the other hand, grid movement may be more practical for some puzzles, and I think you may also be less likely to run into collision problems with it. Anyway, GS players will definitely feel more at home with free movement.

And that I've intimidated myself even more , I'm going so simplify my immediate ambition to

1. Create a single psi-energy puzzle room which players can get through.  I think this will be challenging enough... I think the only reason I'm considering the other stuff is to distract me from this one, daunting task.

Can we identify some of the problems you might be facing? You make this sound a lot more difficult than it should be, when taking into consideration its importance to the game. Unless you wanted a pure puzzle game.

I think the foundation you need is movable, walkable blocks. That definitely sounds doable. It's not the only thing that should be used in puzzles (that likely wouldn't be very interesting), but probably the only basic thing that requires special programming. Once you have that, you can start working from the other direction - make some puzzles (at the theoretical level), and from that, determine what you need to make them more interesting.

I don't think I'm speaking only for myself by saying that not having any battles whatsoever would be disappointing. Maybe include it in your plans at least, but I agree with taking one thing at a time.

[Thunder-squall]

here's a little graphical feat, involving the world map you guys made for your clans.  It's a love file just like the others.  I really recommend checking it out, because for me it really got me imagining what nation-vs-nation dynamics might be like.  I don't think my overworld movement will be standard, after all.

Other updates (which are too minor to warrant an upload):

> Sticking with grid-locked puzzle stuff for now, because otherwise I'll have to develop a platformer-level collision detection scheme, which is difficult.  Free movement is easy; free collision is not.  Even if I free up player movement later, they'll "snap" to a grid location to engage with stuff like blocks or whatever.  (though I killed a lot of time exploring this)

> I didn't solve the draw-order thing, but I did bypass it, by drawing the field differently depending on how the payer is moving.  So it's kind of solved, and I've been thinking of clever ways to prevent this from hindering cut-scenes or whatever in the future.

> Removing diagonal movement.  Just cuz.

> I also made a hat, shield, and weapon for the player token.  Haven't polished them, but I got the basic templates down.

[Teawater]

@World Map: Not much, but it's fine.

>Exactly how difficult are we talking about? I know that we could still use a tilemap for collision data, and I know it's possible to get what tile the player is on by doing player.x / (tileWidth) and player.y / (tileHeight) ; Usually I like tiles to be 8x8, 16x16 or 32x32, so that you can simply do a bit shift. (Which should be faster than division.) ; As for snapping to grid? Is that truely necessary if you can get the player's tile? (Or perhaps you were talking about what the animation looks like.) Collision with NPCs would be checked by each individual NPC, I believe? (Since there are usually not a lot of them in one map--unless you choose that whenever they move, they also modify the collision tilemap.)

>Okay.

>That's fine.

>Good.

[Thunder-squall]

>Exactly how difficult are we talking about? I know that we could still use a tilemap for collision data, and I know it's possible to get what tile the player is on by doing player.x / (tileWidth) and player.y / (tileHeight) ; Usually I like tiles to be 8x8, 16x16 or 32x32, so that you can simply do a bit shift. (Which should be faster than division.) ; As for snapping to grid? Is that truely necessary if you can get the player's tile? (Or perhaps you were talking about what the animation looks like.) Collision with NPCs would be checked by each individual NPC, I believe? (Since there are usually not a lot of them in one map--unless you choose that whenever they move, they also modify the collision tilemap.)

Give it a quick try yourself, then we can talk about the specifics.  It shouldn't matter that we're using different languages, since the algorithms or logic should be the same.  Detecting that a collision has taken place is super simple (i.e. http://love2d.org/wiki/BoundingBox.lua), but then what?

I can post a quick template in love, if you'd prefer to use the same coding system.

[Teawater]

I never said it was going to be easy or hard, I was trying to figure out exactly what part you were referring to when you said "difficult."

If I coded it myself, I would probably take some of it from the code in Golden Sun 1 or 2, just because I like the idea of taking what's already there.

[Thunder-squall]

Then I challenge you to make a simple box pushing demo, and to take code from Golden Sun One or Two.  If you can do it and demonstrate how it works, then I'm sure I can adapt it or make use of it.  You're learning Java mow, right?  What's your first project?

When I say difficult, I just mean it'll require time and persistent effort... And I apologies if I've given the impression that I have infinite time. I do have to make trade offs, just the way you guys have to.  Which means if I take the 10+ hours to play the GBA Golden sun games, then I've basically lost a couple of weeks of coding time.  And if I spend time working on selecting and implementing sprites, then I lose that coding time as well.  Etc etc.  I'm coding this game because I'm ambitious and I think it'll be fun.  But I'm not doing it because I have nothing better to do, nor because I have boundless time and energy.

Ideally I'd break this project into chunks, which could then be delegated.  And that's what I want to do.  I want to find someone who really wants to use their sprites in the game, and then I want to teach them to basic code to do that, and hopefully they'll go off and add more user sprites, animations, etc.  Or I want to find someone who cares about the turn-by-turn battle system, and then work with them on coding the battle system.  Or find someone who cares about inventory management, etc etc.  These are all subsystems that need to be built.  And I think they're best built by people who are passionate about them.

Else I'll get to them when I get to them.

-------------

But if you just want to talk about collision (because you're busy, or whatever), then let's start by assuming that there're two rectangular objects:
player={x,y,w,h} and box={x,y,w,h}.
The letters stand for x-coordinate, y-coordinate, width, and height, respectively.

The collision detection equation is pretty simple (see the bounding example in my previous post).  You basically see if the squares overlap.

Alternately, you could give the objects values for xmin, xmax, ymin, and ymax.  These will update depending on when a player is near something.  I prefer this method because you also know which direction you're colliding with something.  I.e. if x==xmin, then you know you've hit up against something on the left side, and that whatever interaction is about to happen, will happen on the left.

But anyway, let's assume we have a way to detect collision. ie. For all objects near by, detect if there is a collision with the player.
Something like
for j=1,#listOfObjects, do
    DetectCollision( [listOfObjects[j], player)
    -- each listOfObjects[j] is a different rectangular object with a x,y,w, and h value
end

Then what?

Both of these objects will also have to move, so let's give them these additional properties:
vx, vy:  the horizontal and vertical velocities.

The equation for movement would be like:
object.x = object.x + object.vx*dt
These are based on basic kinomatic equations in physics.

So our scenario will be that the player is walking east, and all of a sudden walks into the box--they collide.  Then what?
Then the player starts pushing on the box, and the box moves.


I like to give the player a state variable.  I've used two options for this.
(1)
player.is="walking"
This player.is variable could be changed to "standing" or "pushing" or whatever as need be.

(2)
alternately, you could have a set of Booleans variables.
player.is={
     standing=false,
     walking=true,
     pushing=false,
     angry=true
}

So you could then write equations like
if player.is.angry then player.frownEyebrows() end

I like the second option because you can stack states, and use these to write out complicated logic stuff in a way that's readable.  But since we're looking at a simple example, let's just assume we're using the first option, and that we can make a player behave differently at different times.

So going back to our scenario, the player starts out standing
then starts walking
then collides with the box, and we enter a decision matrix:
Does the player go from walking to standing, or from walking to pushing?

So we need to know whether the box
- is a type of object that can be pushed
- can be pushed in the direction where the player wants to push it.
- is being pushed

For our demo, we're going to assume that these things are always true, so we're not going to worry about it.

So once the player collides with the box, we'll go straight to pushing.
If player.hitRight (has collided with something to the right)
then determine what the player actually collided with.
If the player collided with something that can be pushed, then
if the player is being directed to move right
the player starts pushing,
player.pushedObject=box (this doesn't create a brand new table, but *links* the two tables),
player.pushedObject.vx=player.vx

If player.is.pushing and movingRight then
if player is no longer directed to move right then
player.is.pushing=false; player.pushedObject.vx=0, and maybe some other stuff.

This should be fine for the demo, even though there may be a lot of different contributing factors to the velocity of objects.

And now I'm exhausted.  I'm sure this is all doable, but there's a lot of moving parts I'm going to have to check with and fix, and I just don't want to go through all of that.

[Thunder-squall]

Beginning of February.

Update: I've done NO (game) CODING THIS PAST WEEK WHATSOEVER.  Which is fine, but I just wanted to give a status update.  Other parts of my life have been productive, so that's good.

Short term coding goals for the game: Switch between three game views:
> edit the player
> edit the field
> move player on the field.

So that would be my goal for the end of February.  That's four weeks, with maybe a couple of  evenings of work a week?  Seems doable.  So lurkers could expect 4-8 posts, depending on the rate at which I reach milestones, or feel like I have something to share.

[Today]

Today at 16:40:10

Luna_blade: @Saturos: Your english exams?

[Today]

Today at 16:33:40

Teawater: Can't remember exactly what shae of yellow it was, so not sure it would be too close or not.

[Today]

Today at 16:30:58

Teawater: @KoP: Wouldn't Shiny Gold be for the Sol Clan?

[Today]

Today at 15:37:37

Salanewt: Oh wait, tag doesn't work down here. But yeah, how is your hack going Jamie?

[Today]

Today at 15:37:00

Salanewt: [me] considers giving him the Sol Blade...

[Today]

Today at 15:36:00

Salanewt: Oh my. To be honest though, I'd be more likely to give Briggs stuff from later regions; him being a pirate from another continent and all.

[Today]

Today at 09:36:58

JamietheFlameUser: How not to design boss fights: give human-type bosses stats and equipment on par for what the Editor says their level is and what equipment is available where they're from. You get stuff like an actually scaled to level 21 Briggs with a Great Sword, Silver Plate, Silver Helm, Vambrace, and Leather Boots. God, that was BS.

[Today]

Today at 09:09:49

Saturos: Wow first part of exam is ower (in english) tomorow speaking part.

[Today]

Today at 07:11:35

JamietheFlameUser: Eh, I didn't know the exact chance of Curse screwing you over. Still, that 6% chance to fail to act at all could screw you over when it matters most. The obvious solution, of course, is to stick that armour on a character who doesn't do anything but spam attack moves anyway.

[Today]

Today at 07:10:52

leaf: ...assuming I'm remembering the chance of curse taking effect correctly as 25%

[Today]

Today at 07:09:50

leaf: in fact, you get two turns the majority of the time (~56%), and only completely fail to act ~6%, the remainder of the time getting one action

[Today]

Today at 07:07:49

leaf: I like that stealth armor buff. it wouldn't make sense to do that with the clerics ring available, but if you remove that, it's actually an interesting item. On average, you get ~1.5 turns per round. it's potentially very strong, but carries risks

[Today]

Today at 07:04:59

leaf: lol

[Today]

Today at 06:39:21

JamietheFlameUser: Reading the Venus Psynergy topic and 'lol'ing at Role's reaction to a very simple spell idea I'd had (and still think is awesome), where rock explodes out of the ground from a single point in a focused, cone-shaped burst. Role read me the riot act about not combining elements again. lol.

[Today]

Today at 06:17:58

JamietheFlameUser: Well, one thing I came up with that was actually potentially cool is a modification to the Stealth Armour. I gave it +1 turns, under the assumption that the Cleric's Ring would be removed. You might get 2 actions that round, or 1 action, or maybe no actions at all! RNG at its finest.

[Today]

Today at 06:15:32

Knight of Purgatory: Nice orange text kain. Maybe it should be a shiny gold

[Today]

Today at 06:03:40

leaf: I concur. There isn't much I'd consider worth salvaging from dc in terms of work done, but reading the old threads can be quite amusing

[Today]

Today at 06:01:48

JamietheFlameUser: LOL I'm looking at the DCrisis Items/Equipment section. Role and I were both so immature about it (me especially) that it's hilarious in hindsight.

[Today]

Today at 01:49:48

Knight of Purgatory: Then i think i'll take the entire shop, item and equipment section

[Yesterday]

Yesterday at 23:25:55

Teawater: @Kain: That's certainly nice to know. :)  Poetry time, I go.  Eventually, things will be in automation. As long as there's no procrastination. In the future, say hello to Mr. Name Charger. Don't worry, it's not a Danger. There'll also be Mr. Clan Swapper.  It might make people hyper..... (Or does the best refer to something else? Like the badge shop?)

View All

refresh